Shareware Grab Bag

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Grab Bag / Shareware Grab Bag.iso / 083 / phnxdoc.arc / PHNXDOC.15 < prev next >

Wrap

Text File | 1987-12-04 | 23.9 KB | 597 lines

PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 15.0 ADVANCED USES AND OPTIONS Before you read and try to use any features in this section, be SURE you have read and understand all of the previous sections! Please also note that the text formatting below is not the same as the rest of the documentation because of the large amount of information this chapter contains. 15.1 SECURITY LEVEL, ACCESS AND ALLOWED It is CRUCIAL for you to have a thorough understanding of the relationships between userlevel, allowed, access and overwrite. This relationship forms a basis for much of Phoenix's power and flexiblity and will be essential knowledge to configure future versions. Phoenix will only allow a maximum level of 9999 so please change any existing records and configurations which may be higher than that. If you have any specific questions, please be sure we answer them to your satisfaction and understanding (no question, no matter how 'elementary' is dumb or stupid) because any lack of understanding of this base concept will totally confuse you later when you add the knowledge of the other toggles, some of which are not user level dependent and behave differently with different levels! 1: you should reserve a security level higher than your own, simply to put things that are not in use so you don't see them and forget that you disabled them. 2: If you are going to have co-sysops, put the co-sysop level into config, and put yours above that as 'super sysop' otherwise, make the config level your own. 3: If a user's level is lower than that of a menu command, he will not be able to use that command. The sysop level in config will enable sysop-only commands in read messages, like kill, move, public, etc. Unless you can trust a co-sysop with your checkbook, wife, life, etc, place certain commands above his level so only you can get to them. In the rest of this discussion, we will refer to co-sysop and up as sysop level. 4: NO user level, including YOU will be able to see or change passwords, change security, lock or revoke file transfers, override the system's automatic locking of transfers, overwrite files, toggle the message system public only areas or include to/from, or read comments without specifically giving each user who should be able to, permission to do so in his user record! (see below) 5: COMMENTS- (access or alt+f2) as was stated earlier, comments are now saved to message area #1 as messages to the sysop-name in config. You must give yourself permission in one of 2 ways. The easiest is, once you have entered the main menu, press ALT F2 and you will have permission. This toggle is for any user that is online. There is a command in the user maintenance facility (sysop 5) to do so for others not online. The configuration for comments is very convenient now. As sysop with access (ALT F2), you will read all comments and have the sysop-specific commands in reading messages, [move,kill,undelete,etc]. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 THE ONLY REQUIREMENTS TO READ AND REPLY TO COMMENTS, IS THE PROPER USER LEVEL TO ACCESS AREA #1 (you configure that in the configure files system command) AND THE ACCESS PERMISSION (Z in the user maint. menu, or ALT F2 for someone online, including locally). ONLY SYSOP LEVEL will be able to delete comments or have access to the other sysop-specific commands. Non-sysop level with access will only be able to do harmless things like reply to comments and save them as messages to any base. If there are other messages in area #1, if you allow regular users into area #1, they will only be able to read the messages that are to them or are public. They will not know comments exist in that area unless they have the access toggle set. We chose to do this, rather than create a special area, so you do not lose the #1 area to only yourself. re-configuration of that could be time consuming and a pain at best in an existing system. Sysop level without access will have all the normal sysop commands and abilities for regular messages but will not see comments. Alt F2 has NO other meanings within the system except ability to read comments (along with user level to access area 1) and is a factor in making SUPER SYSOP (you). Replys to comments will be saved as regular messages and you may choose the area to save to but if saved to one of the special areas, publiconly or includefrom, the message will take on the attribute of that area. 6: ALLOWED- (alt+f1) This command has different levels of meaning within the system. SYSOP LEVEL: Assuming that NO menu command is set higher than sysop level, the ALLOWED toggle ALT F1 (or a command in user maint.) will give global access to everything in the system but comments and overwrite files. This toggle affects the ability to do the following (assuming that the user has the proper user level to access the areas in the discussion): IN THE USER RECORD DISPLAY: See passwords, file transfer lockout status, change security, see whether a specific user has any permissions for comments, overwrite files or whether he has this command,and the ability to change these items. IN UPDATE MESSAGE SYSTEM: Use the commands to change the public only status of an area or change the Include To:/From: in message headers for that area. UPDATE FILES SYSTEM is NOT affected by any of these toggles. IN THE MESSAGE SYSTEM ITSELF: Without this ability, the sysop level will NOT see message to:/from: in header for the specified area. He will, however, have the commands to kill, undelete, private , but NOT the move command (in one of the special areas. He will have move for normal areas). PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 With this ability, the sysop level will see message header to/from, and will have the ability to move the message to another base. Those with the allowed toggle set, EVEN THOSE WITH LESS THAN SYSOP SECURITY LEVEL will see the to/from info, and will see the user number report in any message area he has userlevel for. Less than sysop level will, of course, not have access to the sysop-specific commands in the read msgs menus. THE ACCESS (alt f2) AND ALLOWED (alt f1) toggles will also affect fast and slow scan of messages and will determine what information is displayed. They also, along with sysop level create SUPER SYSOP. 7: OVERWRITE FILES- ANY user may be given permission to overwrite files. We recommend that this ability be given after careful thought to what files areas the user has access to, otherwise, it could be disasterous. NOTE: Although there is not a 'delete files' command, with overwrite permission, you may upload a file of the same name. the system will delete the old one after asking permission to do so, and you may abort the upload thereby effectively erasing a file without replacing it. This will ONLY occur WITHIN THE CURRENT FILES PATH. Duplicate file checking is disabled when a "yes" is given to the prompt requesting permission to erase the file. We STRONGLY recommend that you create some fake users with various permissions and experiment to see how the system responds before giving any of your real users any of these permissions. Certain combinations discussed above create Super Sysop which has total access to everything in the system. 15.2 A LIMITS.BBS FILE TUTORIAL The limits.bbs file allows you to dynamically change the maximum daily time limit and logon limit for a particular userlevel. References to Daily and per Login times are set in config. Without this file, if you set Daily to 100 and per Login to 50, any caller will have up to 2 50 minute calls allowed per day, or any number of shorter calls totaling 100 minutes before he is disconnected with 'timelimit exceeded'. Should this happen he cannot log back in till after midnight when his time left is reset. With this file, you may specify different time limits for each user level. How this behaves is dependant on the number in the per Logon limit parm. This number (in limits.bbs) becomes the initial time-left value in his user record (his DAILY time limit). Syntax is: 5,25 7,80 100,200 Using the above examples, the first line is limited time. Since it is BELOW the per Login (50 min per login), that user level will only have 25 minutes total per login and 25 min total for each day. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 The second line has 80 minutes, so since its greater than per login (50 min), he will have 80 minutes total for the day with only 50 minutes that login. He may call back and will have the balance of how long he was on previously, subtracted from the 80 minutes. The third line has 200 minutes per day with 50 minutes per login. Now, if you place a '!' in front, his per login time is that time specified in limits.bbs WITH NO DAILY TIME LIMIT! So: !,100,200 user level 100 will have 200 minutes PER LOGIN and NO daily limit ever! Advantages to this are: 1: Sysop level could have no daily limit and no 'juggling' of Daily or per Login parms are needed to give sysop as much time as needed. 2: Create a 'guest' account with a pre-determined password to allow limited use of your system. simply announce the 'username and password' (useful for business applications) and that caller will only have x time which will be reset each call so other callers using that account the same day will not have a lowered time limit penalty. eg: !,4,15 will give this 'guest' 15 minutes per login and his user record time left will never penalize him. This may be repeated for as many user levels as you wish. An additional field has been included for those who wish to change the per logon limit by user level. syntax is: 4,100,25 10,100,40 15,100 25,200,100 !,100,200 NOTE that the THIRD PARM MUST NOT BE USED WITH THE ! In the above example, the first line for sec level 4 will give 100 min daily time with 25 minutes per login. (remember that the per Login parm is still set to 50 minutes in config). Note no login time for sec level 15. that level gets 100 min / day using the default time set by the per Login parm in config. Level 25 gets 200 minutes per day with 100 min per login. It is very important that if you use the '!' that you NOT have the login (third) parameter! remember that the login time is set to the value after the security level and there is no daily limit when using this flag. You may only omit the LAST parameter (optional login limit)! Do not omit the daily limit and use 2 commas instead. The system is not set up to handle that and unpredictable results WILL occur. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 Schedule times are ALWAYS checked, and if need be, the login time is adjusted to allow for the schedule REGARDLESS OF THE EXISTANCE OF THE '!' FLAG. 15.3 ALIAS.BBS The ALIAS.BBS file search has been enhanced. You may have a name on each line as before, BUT if you are looking for AN EXACT MATCH of a first and last name, you may have BOTH names on the same line separated by a space,comma or semicolon. The maximum is TWO names per line. NOTE that the comma,space and semicolon are delimiters only and are tested for by Phoenix and are stripped and will not become parts of a name either in the file or in the entry of the names from the user. Ex: dr dos dr,dos dr;dos are all the same to Phoenix with dr being first name and dos being the last name. Two names on the same line only qualify for an exact match for both, NOT either one (dos dr will be allowed)! If you want to match either one, each name must be on a separate line. They do not have to be capitalized as Phoenix will format the names. This way, you can flag a certain name while allowing either first or last name combined with something else to pass. Ex: Dr Holloway This name will be allowed by Phoenix as long as either name is not on a separate line. Also, if someone signs on with dr. dos, in the above example, he will be allowed in because it is not an exact match (the period changes the first name). The period is allowed because many professionals like formality and correctness of abbreviation in their names. You may, however, not allow the period simply by putting dr. in the alias file. 15.4 OTHER USES FOR FILES.BBS AND FILES.CLR For those die-hard RBBS people, we have added the ability to create an RBBS-like files area. If you wish only one files area and want all files to reside in that area, then do so. simply use files.bbs as the "dir.dir" (or whatever it is) which will list the classifications of files listings. eg: files.bbs would have in it: 1. pascal files 2. communications files or pascal the pascal language files comm the communications programs. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 the user can then press l;1 or l;pascal to see the files listings of that "area". the naming conventions for the list file will be <first name>+.* so, if he must select "1" then the filename will be 1.bbs , or, if he must select "pascal" then it will be pascal.bbs. these files follow the same .bbs/.clr rules the normal files.bbs would. The disadvantage to this system is that the sysop MUST create a separate upload path (Phoenix will update the files.bbs otherwise) and the sysop must update the appropriate files listings manually. This type area may co-exist with other Phoenix-type areas. NEW AND MATCH WILL NOT WORK FOR THIS TYPE OF AREA! No error will occur, simply nothing will be shown for that area. AN INTERESTING SIDELIGHT to this is- you may place a "filename".bbs in any area, and leave it private. give that name to a trusted user and you may place private files for him in that listing and the chance of anyone else guessing the name or even knowing its there is minimal. This will not affect Phoenix's use of the files.bbs. Phoenix will not know about this file until the user accesses it and will forget about it after dumping the information to the user. There is no command or configuration needed to use this feature. It is a side effect of chaining the "list areas" command. Simply place the file in the appropriate path, and use it. 15.5 ADVANCED USES OF THE PHOENIX MENU SYSTEM PLUS (tm) You may create your own menu system based on the .mnu command menus that will use ansi colors, or simply your own unique style menus. Note that a menuxx.mnu command file MUST be present for each menu you create or it will not be used. TO BE CREATIVE: The menu system MUST have a file present called menu.sec. this file can have up to 24 different security levels each on a SEPARATE line. THESE LEVELS MUST BE IN DESCENDING ORDER! These security levels will only describe the level of the text menu you wish to send to the user who has that level (see below for a better description). Descending order helps Phoenix to speed comparisons with the users level. Each security level will correspond with a menu name/level combination. this means you may create up to 24 different menus for each section of Phoenix. (24 main menus, 24 sysop menus, 24 files menus, 24 message menus, 24 of each of any of the 25 menus Phoenix now has available to you). That is a bit extreme, but the capability is there if you want it. You may create this menu level file with copy con, or your favorite text editor that will save a STANDARD DOS TEXT FILE. Ex: a sample menu.sec has: 100 4 meaning there are two levels of menu files, security levels 4 and 100. There can be up to 4 characters for the seclevel 9999, which is the MAXIMUM security level. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 expert levels of x1 and x2 will simply have what they see now with no changes. They will only get the menu name and a commandline. The menu0.mnu file MUST exist or Phoenix will not run at all! These command files (menuX.mnu) are just that, they tell Phoenix what commands do what, at what levels, and make up the command line prompt as well as the standard menus. Expert x0 level, will be dumped the menu text files which must have their names formatted a certain way. These files will follow the .bbs and .clr extension rules just like other files. The key is in the first name of the file. Using the menu.sec example above and assuming the sysop is making ansi files available,and 100 is sysop level, the menu text files will be formatted this way: COMMAND FILE MENU TEXT FILE ANSI MENU TEXT FILE ------------------------------------------------------------------ MAIN.MNU {menu0.mnu} M0-100.BBS M0-100.CLR M0-4.BBS M0-4.CLR SYSOP.MNU {menu3.mnu} M3-100.BBS M3-100.CLR MMS.MNU {menu1.mnu} M1-100.BBS M1-100.CLR M1-4.BBS M1-4.CLR FILES.MNU {menu2.mnu} M2-100.BBS M2-100.CLR M2-4.BBS M2-4.CLR NOTE THAT THE MENU NUMBER MUST BE THE FIRST SERIES OF CHARACTERS!! M stands for menu and the number after it (1 thru 25) is the menu number, then a "-" and the security level (up to 9999). So, M5-100.BBS is a text file for menu 5 at security level 100. Please note that you do not need any of the high level menu text files unless you want them. You may have only the lower level menus and have the utilities for sysop command for yourself but it will be 'hidden' since its not in the lower level menu, but it WILL be in the commandline if security level is correct. If menu.sec is present, and you do NOT create a menu text file , Phoenix will default to the .mnu files automatically. Of course, if the .clr file is not present, the .bbs file is dumped and if neither is present, the .mnu descriptions are used. SOME POINTS TO REMEMBER: If the security level of the user is LOWER than the lowest security level in menu.sec, the standard menus are dumped. Since these are TEXT files (or ansi files), you may design your menus ANY WAY YOU WISH! The only limitation is that you should keep to the commands you have installed in each menu of Phoenix, but you may segment the commands into blocks with different color backgrounds, or any way you wish. PHOENIX REMOTE COMMUNICATIONS SYSTEM DECEMBER 4, 1987 User sec. levels in between menu sec levels, say security of 6 in this example, will be dumped the level 4 menu. Phoenix will ALWAYS dump the next lower menu security level if an exact match is not found. Ideally there should be as many menu text files as you have DIFFERENT security levels in the command files. That way, the user gets to see only the commands he has access to. You do NOT have to match the limits.bbs file. That only defines a users time on the system, so you can have as many different security levels and times as you want in that file and they all will only see one menu unless they cross the next higher menu security level. You may have,for example, a new user get the standard Phoenix menus. Regular users can get the standard menus also, maybe with more commands available (as it can be with Collie 1.2). However, you can treat your more priveledged users who get the same commands as regular users but get more time to better looking and more artistic menus and have real ansi menus too! This can be for any level, you simply must have the corresponding file with a menu-security level name, and the security level listed in menu.sec for it to be displayed. You may also choose to have only one menu text file for all levels including the sysop level. In that case, the level 100 (or your highest) menu should be renamed to the level 4 (or your lowest) menu. If you dont want ansi, you only need to have one menu text file for each .mnu file, or, none at all,or just some,or use the standard Phoenix menus. If menu.sec is missing, even if the menu text files are present, only the standard menus will be used. ALL THE COMMANDS WILL STILL HAVE THEIR MINIMUM SECURITY REQUIREMENTS (AS DEFINED IN THE .MNU FILE), EVEN THOUGH THE COMMAND WILL SHOW IN THE TEXT FILE (if you choose only one menu per command file and put the command into the text file). IT WILL NOT SHOW ON THE COMMAND LINE AND IF THEY TYPE A COMMAND THEY DONT HAVE ACCESS TO IT WILL SIMPLY SAY "Sorry, that is Invalid". The main thing to remember is that the files you create are dumped with the SAME RULES as welcome1 or any of the other .bbs / .clr files. the .mnu files still determine all the criteria for commands and program flow. Just to re-state, Phoenix will search the levels found in menu.sec for a level that is EQUAL to or if its not there, LOWER than the security level of the user online. If one of these two criteria are found, the appropriate menu text file is dumped to him. If the user has a security level LOWER than the lowest level listed in menu.sec, the standard Phoenix menu will be used. If a level is found that satisfies Phoenix's test, the .bbs /.clr rules apply, that is, if ansi is enabled and ansi files are dumped, if the .clr file is not there, the .bbs file will be dumped. if NEITHER are there AND the criteria for menu.sec ARE SATISFIED, Phoenix will use the standard menu. A user will never go without some kind of menu. Also remember, x1 and x2 expert users will NOT be dumped ANY of these files as they only see command lines or just menu names. If something is not right, no error will occur, simply the wrong menu or no text menu will be dumped and Phoenix will default to its standard menu.